Pervasive, distributed provision of services such as product brokerage

ABSTRACT

A client-server computing system suited particularly for clients of varying functional capabilities. Information handling capabilities are provided at the client and server on a customized, as-needed basis. When a service is needed by a client, the server determines a number of factors that may be relevant to the manner in which the service is to be provided. Then, the server selects from between two or more services having different executable code, and uploads the selected service to the client. Thus, the code may be tailored to the client&#39;s capabilities, or other aspects of its function. Services are not permanently retained by a client; rather, the client performs an analysis to determine whether services should be retained or purged. Also, state information is not permanently retained by a client; the server retains the information and uploads that information to the client. The server also manages its resources by loading service components on an as-needed basis.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/871,929, filed on Jun. 1, 2001 by Richard Dean Dettinger et al.(ROC920010022US1), the entire disclosures of which is incorporated byreference herein.

FIELD OF THE INVENTION

The present invention relates to client server computing systems inwhich services provided by the client and server are dynamically loadedto the client from the server.

BACKGROUND OF THE INVENTION

With the proliferation of the Internet and applications utilizingInternet or other networking systems, increasingly, data has beenaccessed from servers using diverse platforms in varied locations andcircumstances. Currently, a variety of Internet clients are availablefor accessing Internet information, including embedded devices (e.g.,browsers in household appliances), palm size personal computers, palmsize organizers, desktop personal computers, lap top computers, cellulartelephones and other platforms that are being developed presently. Thediversity of platforms available for accessing Internet content isexpected to expand, particularly as wireless data networks becomeincreasingly available to users.

Each of the variety of clients currently available has unique memoryperformance and functionality constraints. The unique physicalcharacteristics of each client, or the desired functional use of theclient, implies that each client will have different processing code anddifferent input/output functionalities available to it.

This diversity of platforms raises a number of difficulties. First, mostInternet content, and content on other networks such as corporateintranets, has been developed to facilitate communication with a singletype of client, namely, a desktop or notebook computer having a standardsize display screen, a full alpha/numeric keyboard, and frequently alsoa pointing device. Content developed for this client platform is notwell suited for use in and viewing on other dramatically differentplatforms, such as embedded devices, palm size personal computers,organizers and cellular telephones. To date, the content that is easilyavailable through such non-standard platforms has been limited to thatmade available in conjunction with the manufacturer of the clienthardware.

Second, diverse platforms require different software capabilities tohandle content delivered over a network; these capabilities aredifficult to predict in advance or to install in advance of theirdesired use. Although it has been known to install functions forInternet content on an as needed basis, the methodologies that have beendeveloped are not particularly suitable for diverse clients with variedand potentially highly limited capabilities and resources.

For example, Microsoft Internet Explorer includes an install on demandfeature in which Internet Explorer will recognize when givenfunctionality is needed to properly present web page content, and inthis condition will prompt the user to download and install the neededfunctionality. The difficulty with this approach is that the installedfunctionality is permanently installed at the client computer, and thusmay consume precious resources, particularly where the client haslimited resources such as is the case in palmtop or cellular telephoneclients.

A second example, the Java Virtual Machine functionality has beenpromulgated by Sun Microsystems as an open source programming languagefor use with web-based content. In a Java-enabled website, Java VirtualMachine (VM) code for a page is downloaded and initiated as part ofviewing the page. The Java Virtual Machine code is retained in memoryand executed, so long as the page is viewed by the user. When the userdeparts the page the Java Virtual Machine code is discarded. Adifficulty with the Java methodology is that the Java Virtual Machinecode for a given web page is identical for all clients visiting thepage, and thus is not adaptable for clients with radically differentfunctionalities and capabilities. Furthermore, the Java Virtual Machinecode for a web page is downloaded in full upon accessing the page,potentially requiring resources in excess of those available in a clientwith limited computing or storage capabilities. Finally, because JavaVirtual Machine code is discarded upon exiting the page associated withthe code, the user upon returning to that page must reinitialize his orher browsing state, such as information retrieved or data entered,because that state information is not retained when the Java VirtualMachine code is discarded.

A third difficulty arising from the use of diverse clients withpotentially widely varying capabilities, arises when attempting toretain information on the state of interaction of the client with theserver. Web browsers such a Microsoft Internet Explorer haveincorporated a functionality known as “cookies”. In this methodology, aserver may store a small file known as a “cookie”, on a client computer,that contains some status information. “Cookie” files are stored andretrieved by the server, under supervision of the client's browsersoftware. In some cases, cookies may be used to restore the state of auser upon return to a web page. However, cookies may consume aninordinate amount of a client's storage resources. Furthermore, due tosecurity concerns, many users dislike the “cookie” approach of storinginformation on a client's computer system. For either or both reasons,many users prevent storage of cookies on their client systems.

A further, related, difficulty arises in a server attempting to provideservices to a wide variety of clients. Specifically, in a typicalserver, all data and executable code needed to provide services toclients that may connect to the server, are loaded in the server at alltimes. This approach, while insuring that all possible services arealways available from a server, can consume substantial resources of aserver. This is particularly true where multiple different styles ofclients and/or multiple different services may be utilized from theserver. As unique executable code or data is developed for differentunique clients, the duplication and proliferation of different serverfunctions will be exacerbated.

The UNIX daemon known as INETD, attempts to resolve this problem bydefining a static list of services that may be provided by a server.This list is used to load needed services when those services aredemanded by the server. Unfortunately, the UNIX INETD daemon suffersfrom the limitation that the services provided by the server must bepredefined and be in a static listing, limiting the adaptability of theserver to changing conditions.

It can thus be seen that the state of the art has substantiallimitations in managing, on both the client and server, the emergingenvironment characterized by diverse clients connecting to server forproviding services over a network.

In the preceding discussion, and in the follow explanation, of theinvention, the word “service” will be used to refer to executable codeor an executable process, or data utilized in such a process, or both,in any combination, that provides an information handling function.Furthermore, a “service” will be understood to comprise client andserver components, which interact to provide an information handlingfunction, each component of which may include executable code, data, orboth, in any combination. The client and server portions of the serviceinteract and interoperate to provide the desired overall informationhandling functionality of the service.

SUMMARY OF THE INVENTION

In accordance with a first aspect of the present invention, theabove-noted drawbacks of prior client-server computing systems areameliorated by providing information handling capabilities that are partof a service to a client computer system on an as-needed basis.Specifically, when a service is desired by a client that is notcurrently available to the client, the client requests the service froma server, and the server in response determines a number of factors thatmay be relevant to the manner in which the service is to be provided.These factors may include such facts as the operating system of theclient and server, the connection speed and cost, the current time ofday, and the geographic locations of the client and server, amongothers. In response to the collected factors, the server selects frombetween two or more services having different executable code, anduploads the selected service to the client. Thus, for example, a palmtopor desktop/laptop client having a relatively small or less colorfuldisplay may receive virtual machine code particularly suited for itssmall size or limited color capabilities, whereas a desktop computerwith a large screen and large color palette may receive virtual machinecode taking advantage of these features.

In accordance with a second aspect of the present invention, the limitedresources of a client computer system are preserved by eliminatingunneeded previously loaded services. Specifically, the client performsan analysis of the usage of services to determine whether those servicesshould be retained or purged. Those that ought to be purged, e.g., thosenot being used or which have not been used recently, are removed fromstorage in the client, saving storage space. The period of disuse of aservice, and/or the presence of a connection to a server relating to theservice, or other factors may be used in determining whether a serviceought to be purged.

In accordance with a third aspect of the present invention, the use of aservice by a client is facilitated by retaining state information at theserver, for delivery to the client. In this way, the client has theadvantage of maintaining a state of interaction with a server, withoutthe disadvantage of consuming storage space for state information suchas “cookies”. In accordance with this aspect, when a client connects toa server, state information relating to prior interactions of the clientand server is uploaded to the client along with executable code of aservice, so that it may be used by the client in subsequent execution ofthe code and provision of the service. In this way, a client mayefficiently use a server by, for example, returning to a database querygenerated during the immediately previous session with the server. Thisaspect of the invention is particularly useful for homogeneous clientsoperating on battery power and expensive wireless connections, and thusfrequently connecting and disconnecting from a server.

In a fourth aspect, the invention features a server configured tofacilitate support for a wide variety of services, in which the serverloads services on an as-needed basis. Specifically, in accordance withthis aspect, a server responds to a request for a service from a clientby selecting an appropriate one of multiple possible services, and thenloading the selected service and executing the service. Because servicesare selected at the time of a clients' request for service, and are notuniquely associated with each client, the server has the advantage ofreduced overhead at all times that a given service component is not inuse, while retaining flexibility to respond to various differentsituations using different clients.

The above and other objects and advantages of the present inventionshall be made apparent from the accompanying drawings and thedescription thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate embodiments of the invention and,together with a general description of the invention given above, andthe detailed description of the embodiments given below, serve toexplain the principles of the invention.

FIG. 1 is an illustration of a networked computer system including aserver and clients of a variety types including cellular telephones,palm devices, laptop and desktop computers, and other various clients.

FIG. 2 illustrates the activity of a server such as that shown in FIG. 1in accordance with the principles of the present invention in respondingto a request for services from a client.

FIG. 3 illustrates the activities of the server such as that shown inFIG. 1 in accordance with the principles of the present invention inresponding to disconnection of a client from the server.

FIG. 4 is a flow chart illustrating activities of a client in accordancewith the principles of the present invention.

FIG. 5 is an illustration of data structures that may be used inaccordance with one implementation of the principles of presentinvention for providing services for brokerage of real estate,automobiles, or other items of value.

FIG. 6 is a flowchart of various services that may be activated inaccordance with the implementation of a brokerage service.

FIGS. 7A and 7B illustrate a brokerage service being performed on a palmoperating system client, including display of listings and details of aparticular listing.

FIG. 8 illustrates operation of a brokerage service on a cellulartelephone client, showing selection of items suitable for bidding.

DETAILED DESCRIPTION

Referring now to FIG. 1, a network computing environment 10 consistentwith principles of the present invention can be explored. A server 12 isconnected to a network such as the Internet 14 for communication witheach of a plurality of heterogenous client devices 16 a through 16 e.These clients may include, for example, a cellular telephone client 16a, a desktop personal computer client 16 b, a laptop computer client 16d and a palmtop computer or other palm device 16 e.

The essential functional elements of a server 12 are illustrated in FIG.10, including the information that is utilized thereby. Specifically,server 12 includes a mass storage device 20 such as a direct accessstorage device or DASD, as well as a memory 22 such as DRAM memory fortemporary storage of information during operation of server 12. Server12 further includes a display 24 and keyboard 26 used in interactingwith server 12. Server 12 may further include one or more communicationsinterfaces 28 for connecting to network 14 and/or other computer systemsor peripheral devices.

Within mass storage device 20 are a number of data structures used inaccordance with the principles of the present invention. Specifically,mass storage device 20 stores server virtual machine code in an area 30,which code may be loaded into memory 22 on an as-needed basis inaccordance with the principles of the present invention. Also, massstorage 20 may include client virtual machine code 32 which may beuploaded to clients in accordance with the principles of the presentinvention, on an as-needed basis. Also, as described below, stateinformation relating to the state of interaction of clients with server12 is stored in an area 34 on mass storage device 20.

The foregoing areas of mass storage device 20 are accessed by aprocessor or processor network 36 in operation of server 12 inaccordance with the principles of the present invention. Processor orprocessor network 36 utilizes memory 22 for storage of active clientinformation as well as server virtual machine code for servicescurrently being provided by server 12. Specifically, memory 22 stores aclient list 38 identifying clients currently accessing server 12, oralternatively a count of a number of clients accessing each service ofserver 12. This information is utilized in management of services thatare loaded within server 12 at any given time. Memory 22 further stores,in an area 40, virtual machine code utilized by server 12 in providingthe services to the connected clients. Server 12 further stores, in anarea 42, operating system code defining an operating system for server12.

As seen in FIG. 1, the client may take a variety of forms 16 a-16 e, butthe functional elements of a client typically take the general formshown with reference to client 16 c. As seen in FIG. 1, the typicalclient includes a processor 44 for processing data, and a keypad 46 anddisplay 48 for interacting with a user of the client device. The form ofprocessor 44, keypad 46 and display 48 may vary widely depending uponthe nature of the client device. However, a typical client device willinclude at least these elements for interacting with a user. Typically,a client will further include a communications interface 50 forexchanging data with a server such as server 12 over a network such asnetwork 14. Also, a typical client will include a memory 52 for storingdata and program code used by the processor 44 in performing functionsof the client. As seen in FIG. 1, the memory 52 will typically includean operating system and a portion 54 defining general operations of theclient, as well as additional information used by the operating system.In accordance with the principles of the present invention, thisadditional information may include Java Virtual Machine (VM) code storedin a region 56 of memory 52, and state information stored in a region58. The Java VM code comprises programming instructions in accordancewith the Sun Microsystems Java programming language, used in providing aservice as is known in the art. The state information in region 58 ofmemory 52 relates to a current state of operation of the client deviceutilizing the Java Virtual Machine code.

Client devices of various forms may also have additional functionality,as shown within dotted lines in FIG. 1. Specifically, a client may havean external interface such as an infrared (IR) or universal serial bus(USB) interface for exchanging data between the client device and othercomputer systems. The client device may also include a mass storagesystem 62 for storing larger quantity of data that can be held withinmemory 52.

Referring now to FIG. 2, operations performed by a server such as server12 in a carrying out principles of the present invention can beexplained. The server responds to a request to participate in providingservices in step 70. Initially, the server identifies factors relatingto the manner in which the client should provide those services, in step72. The factors that may be considered in identifying the appropriatemanner in which to provide services include the operating system of theclient or the server, the connection speed of the network connectionbetween the client and the server, and metrics relating to the cost ofthe connection between the client and the server, such as the cost perdata unit transferred or cost per connection time unit. Further factorsthat may be invoked are the time of day in which the request forservices is made, such as in a situation where a service may be providedonly during business hours of the sponsoring organization or may beprovided in a different manner outside of normal business hours of thesponsoring organization (e.g., orders may be received but not confirmedoutside of business hours). Finally, the provided services may beselected or modified based upon the physical location of the client andor the server, so that, for example, services may be provided in amanner that is responsive to the geographic location of a client.

Following identifying client factors in step 72, in step 74 thesefactors are used to select the services and the level of functionalityof those services that need to be supported by the server to provide theidentified service to the client. A noted above, different clients maybe provided with services in different manners. A client with a small orlimited functionality display may be provided the service using asimplified screen display. A client with a limited communications speedmay be provided the service so that the data transfer is minimized,e.g., data such as a list of records being browsed by the user may beprovided as the browsing is performed, rather than in advance of thebrowsing. In each case, the component of those services provided by theserver may be different.

Thereafter, in step 76, it is determined whether the server has alreadyloaded the necessary service components needed to provide the selectedservice and level of functionality. It will be noted that the server mayalready be providing similar services to another client, and thus mayhave already loaded the necessary services components. If, however, thenecessary server components have not been loaded, then in step 78 theselected services that are not loaded are loaded into the server.

It will be noted that some services need to be provided in a particularcontext or under particular controlled situations. For example, someservices may be provided only when encryption of data is being used.Similarly, services may be provided only when compression is being used.Finally, some services may only be provided when authentication of thoseservices is available. In any of these situations, it is necessary totrigger initialization to establish the appropriate conditions such thatservices are provided in the proper context. Thus, in step 80, anyinitialization actions such as starting encryption or compression, orrequesting authentication, are triggered. Thus, any such initializationactions that must be performed, are preformed at the time the servicesystem is installed.

It will be noted that initialization actions may not be successfullyperformed. For example, the client may fail authentication or may not becapable of encryption. In this case, from step 80, processing continuesto step 81, in which the request for service is denied, any servicesloaded in step 78 are unloaded.

After step 80, or immediately after step 76, if all server components ofthe desired services have been loaded, in step 82 the client requestingthose services is associated with the services being used by thatclient. This step is performed so that it may be determined when aservice is no longer being used by any clients and thus may be discardedby the server. The information retained with respect to client use ofservices may identify specific clients associated with specificservices, or may take the form of a counter to identify the number ofclients associated with each service. In either case, sufficientinformation will be available to discard server components of servicesthat are no longer being used by any clients.

After the foregoing initialization of the server, in step 84 the serveridentifies the service components that need to be uploaded to theclient. Thereafter, in step 86, the client is triggered to upload theselected services. After the services have been uploaded by the client,in step 88 it is determined whether any stored client state informationis available for any of the requested services. If so, then in step 90the client is again triggered to upload this state information so thatthe client may recommence use of the selected services with a state thatcorresponds to the most recent state of that client using thoseservices.

After step 90, or after step 88, if no state information is stored, theclient and server proceed to execute the selected services. Duringexecution of the services, the server tracks the state of the client,i.e., tracks data entries made, data retrievals requested or other stateinformation that can be used to restore the state of the client upon asubsequent request for the same service.

The execution of the services and concurrent tracking of client state isrepresented by step 92 in FIG. 2. This process continues until theclient disconnects from the server.

Referring to FIG. 3, when a client disconnects from the server, and thusdiscontinues use the services, as signified by step 100, then the serverevaluates its use of server components of the services formerly providedto the client. In a first step 102, the client state informationcollected during the client's use of the service is closed and storedfor later use if the client reactivates the service. In a further step104, the client is disassociated with the server component of theservice that has been provided. As noted above, this may involve movingthe client from a list of clients associated with those service or mayinvolve decrementing a counter of the number of client utilizing aservice. Thereafter, in step 106, it is determined whether any clientsare continuing to use the server components of the service that has beenterminated. If not, then in step 108 the unused server components of theservice that are configured to be unloaded are unloaded from the server.It will be appreciated that some server components of services may beconfigured to remain resident in a server even in the instance that noclients are using those services. This may be done to increase the speedof availability of services or for other reasons. Those servercomponents of services that are configured to be unloaded in non-use,however, are unloaded in step 108 after completing use of thosecomponents.

Referring now to FIG. 4, the activity of a client in performing servicescan be explained. In a first possible scenario, a user may request aservice that is not available within the client, such as by accessing anInternet location (either directly or under the control of anapplication or applications programming interface), or accessing a linkto an Internet uniform resource locator (URL). In response to thisaction in step 122, a connection is established to the server and thedesired services are requested.

Then, in response to activity in the server discussed above, in step 124the client provides to the server factors relating to the client to beused in identifying the services and functionality of those services tobe provided to the client. Next, in step 126, the client may betriggered for various initialization actions as discussed above, such asauthentication. If such an action is triggered, then in step 128 theappropriate initialization is performed.

Thereafter, in step 130 the client may be triggered to upload clientcomponents of one or more services. If so, in step 132 those servicesare uploaded from the server. Thereafter, in step 134, the client may betriggered to upload state information, in which case in step 136 thestate information is uploaded from the server.

After the following steps, the client has been provided with necessaryclient components to perform the requested services in accordance withthe client factors provided to the server. As a consequence, in step140, the requested service is executed.

It will be noted that, in some instances, a user may request a servicethat has already been loaded in a client. For example, may not have beenpurged from the client after the most recent use of the service if theclient is configured to retain services after their use has ended. Asanother example, a user may wish to have two active windows accessingservices, to facilitate comparison or manipulation of data relating tothe services. In this case, when a second window to the service isopened, the client's component of the service may already be loaded inthe client. In such a circumstance, represented by step 142, the clientmay proceed directly to step 140, and execute the requested serviceswithout requiring uploads or initialization.

The execution of the requested service, represented by step 140, iscontinuous until the user disconnects from the service or the serviceremains unused for longer than a time-out period. As noted above, someservices may be retained even if unused so as to avoid reloading. In thecase of either a time-out of a service, or a disconnection of the userfrom the service in step 144, if the service is to be purged, then instep 146 all services associated with the time-out or terminatedconnection are unloaded from the client. This frees resources of theclient for other services.

In use, the principles of the present invention may be utilized tosubstantially facilitate use of diverse heterogeneous clients in a widevariety of applications. One such specific application is illustrated inFIG. 5 through FIG. 8. In this application, brokerage of items of valuesuch as homes or automobiles is provided utilizing service components ina client and server in accordance with the principles of the presentinvention.

FIG. 5 illustrates records for storing information utilized in abrokerage application of this kind. Specifically, a plurality of productrecords 150 store information about the products that are subject to thebrokerage service. For example, products may be homes offered for salethrough a multiple listing service, or automobiles offered for sale, orany other items available for sale. Each product is associated with anunique identifying number or UIN that distinguishes the product fromother products. Each product record 150 includes the UIN as well adescription and name for the product, and an identifier for a brokerresponsible for brokerage of the product. The records further include anidentifier for a calendar of availability of a product such as a dateson which a home may be viewed by a prospective home buyer or dates whenan automobile may be test driven by a prospective buyer. Product records150 are also illustrated to include a price that may be displayed whenbrowsing through records. A variety of other information about productsmay be included in the product records 150 as appropriate for aparticular application.

As noted above, products are linked to brokers. This link is formedusing a broker identifier. A plurality of brokerage records 160 identifyeach of a plurality of brokers of the products described in the productrecords 150. Each broker is identified by a broker identifier, by name,and by contact information. Furthermore, the calendar for the brokersuch as the availability of the broker to show products to a possiblebuyer, is identified by a calendar associated with a calendaridentifier.

As noted, products and brokers are linked to their calendars. This isdone using a calendar identifier which can be used to identify one ofnumber of calendar records 170. Calendar records 170 store informationabout a calendar, such as a calendar of availability, or a calendar ofunavailability of a product or broker. Each calendar record is shown inFIG. 5, and contains a calendar identifier linking the calendar to abroker or product, as well as a number of appointment entries eachrelating to an appointment on the calendar.

Referring now to FIG. 6, the use of data structures of FIG. 5 in theimplementation of brokerage-related services can be explained. As notedabove, a user may initiate one of a variety of services, in a variety ofways, and in accordance with the principles of the present inventionthese services are loaded as needed, and unloaded when no longer needed.In the case of a brokerage server, a user may begin use of the serverby, in step 180, requesting a “browse offline” service to browse a groupof product records. In response, in step 182, product records may beuploaded to the customer's client device, as part of a service includingthat data as well as virtual machine code for browsing that data.Thereafter, in step 184 the client may execute the code to execute thevirtual machine code that has been uploaded from the server to view theproduct records uploaded from the server as provided by the “browseoffline” service.

Another manner in which a user may begin use of a brokerage service isillustrated in step 186, in which an user requests a “browse online”service to browse product and record data online. In response to thisrequest, in step 188 virtual machine code to browse records is uploadedto the client device. Thereafter in step 190, the client executes anonline browsing routine that has been uploaded from the service.

It will be noted that the decision whether to browse product dataoffline or online may be made by the user, or alternatively, may be madeas part of evaluating factors relating to the client to determine themanner in which a generic “browse” service is to be provided to thatclient. In the latter, case, the user would request a “browse” serviceand in response, based upon an evaluation of factors including theconnection speed of the client and its storage capacity, a decisionwould be made by the server whether to perform an offline or onlinebrowse, after which the interaction with the client would proceed asshown in steps 180-184 (for an offline browse) or as shown in steps186-190 for an online browse).

In either of the above scenarios, the client may browse through productrecords presented in a summary fashion to identify a product record ofinterest. When a product record of interest is identified, typically auniversal identification number (UIN) is obtained from the record beingbrowsed, and used to select additional data regarding the product thathas been identified. This may be done manually, or preferably the UINmay be automatically used in requesting a new service when a recordincluding that UIN is designated by the user by, e.g., double clickingupon the record.

It is also possible that a user may directly identify a universalidentification number for a desired product, such as if that number isadvertised on a “for sale” sign associated with a house, or is includedin an advertisement for a automobile for sale, or in other circumstanceswhere an UIN may be directly identified to a customer.

In any of these scenarios, as symbolized by step 192, a user may requesta service for viewing a specific product's data, identifying thatproduct by its UIN. In response, in step 194, the product record andvirtual machine code to view that record are uploaded to the clientdevice, as the client component of a new “view record” service. Then, instep 196, the client executes the view record virtual machine code toprovide a user with the complete record of the product, as uploaded fromthe server.

It will be noted that a client may request other services in the processof using a brokerage service in accordance with the principles of thepresent invention. For example, in step 198 the user may request aservice to schedule brokerage for an identified product. In this case,in step 198 the client requests a “schedule brokerage” service that willbe used to schedule brokerage for a broker associated with a selectedproduct. In response in step 200, brokerage and calendar records andvirtual machine code are uploaded to the client device. Next, in step202 the client device executes the brokerage scheduling service uploadedfrom the server to permit the user to schedule brokerage with the brokerfor the product of interest.

The client may also access other services in a similar manner. Forexample, in step 204, a client may request a service provided by afinancial firm, based upon advertisement for the firm included in aproduct record, using a URL for the financial firm identifier, or usinganother link to a desired product's record. The financial service thenuploaded to the client may be used to request financing for purchasingthe product, or an advance of credit for purchasing the product, inaccordance with a revolving credit account.

Alternatively, in step 206 the client may contact another form oforganization, such as a transportation organization (air line, taxiservice, etc.), using a URL or a link to a product, or other identifier.The client may request transportation services to visit the broker orproduct and/or to transport the product, as part of purchasing theproduct.

FIGS. 7A and 7B are illustrative examples of operation of a Java VirtualMachine displaying real estate brokerage information in accordance withthis example of the present invention. In FIG. 7A, it can be seen thatsummary information for a number of product records, including theaddress and price associated with each record, are listed in connectionwith a browsing service such as an offline browsing service or an onlinebrowsing service. FIG. 7B illustrates an alternative service in whichdetails about a particular product record are displayed in accordancewith a view record service as described in steps 192 through 196. Itwill be noted that, although the browsing and product informationservices are distinct services, their screen appearance is compatibleand thus both services appear to be seamlessly connected parts of asingle application.

Referring to FIG. 8, it can be seen that in different varieties ofclient devices, services may result in substantially different functionsor operations. For example, on a cellular telephone as illustrated inFIG. 8, browsing of product record information is performed on thecellular telephone screen using a format that is adapted for a cellulartelephone, rather than a format adapted for a palm device as is shown inFIGS. 7A and 7B.

Thus, it will be appreciated from the foregoing that the presentinvention provides improved method for providing services over acomputing network to a plurality of diverse heterogeneous clients andfor providing those services in a manner that efficiently uses resourcesof the server and the clients while adapting to the increasingly widevariety of client platforms through which such services can be provided.

While the present invention has been illustrated by a description ofvarious embodiments and while these embodiments have been described inconsiderable detail, it is not the intention of the applicants torestrict or in any way limit the scope of the appended claims to suchdetail. Additional advantages and modifications will readily appear tothose skilled in the art. For example, while the present invention hasbeen described in the context of client and server computer systems,those skilled in the art will appreciate that the mechanisms of thepresent invention are capable of being distributed as a program productin a variety of forms, and that the present invention applies equallyregardless of the particular type of signal bearing media to actuallycarry out the distribution. Examples of signal bearing medial include:recordable type media such as floppy disks (e.g. a floppy disk) and CDROMS, and transmission type media such as digital and analogcommunication links, including wireless communication links. Theinvention in its broader aspects is therefore not limited to thespecific details, representative apparatus and method, and illustrativeexample shown and described. Accordingly, departures may be made fromsuch details without departing from the spirit or scope of applicant'sgeneral inventive concept.

1. A method of providing an information handling capability to a clientcomputer system in a networked computer system comprising client andserver computer systems, comprising the following steps performed at aserver computer system: identifying factors relevant to provision of aninformation handling function by said client computer, selecting one ofat least a first and a second service to be uploaded to said clientcomputer based upon said factors, said first and second servicescomprising different executable code for providing said informationhandling function such that said first and second services are capableof performing the same information handling function with differinglevels of functionality, and delivering said selected service to saidclient computer system, so that said information handling function maybe realized by said client computer upon execution of code within saidselected service at said client computer system.
 2. The method of claim1 wherein said services comprise data in addition to executable code. 3.The method of claim 1 wherein said factors includes the operating systemused by said server computer system.
 4. The method of claim 1 whereinsaid factors includes the operating system used by said client computersystem.
 5. The method of claim 1 wherein said factors includes thebandwidth of a communications connection between said client and servercomputer system.
 6. The method of claim 1 wherein said factors includesthe date and/or time of day.
 7. The method of claim 1 wherein saidfactors includes, the cost of a communications connection between saidclient and server computer system.
 8. The method of claim 1 wherein saidfactors includes the physical location of said client and/or servercomputer system.
 9. The method of claim 1 wherein said informationhandling capability comprises providing brokerage information to a userof said client computer system, wherein said brokerage informationcomprises product information and pricing, and wherein said product isselected from the group consisting of real estate property, chattelproperty, and an automobile.
 10. The method of claim 1 wherein saidinformation handling capability comprises providing at least one ofscheduling information, financial information and transportation serviceinformation to a user of said client computer system.
 11. A server in anetworked computer system comprising client and server computer systems,said server comprising: a processor, a communications interface forconnecting to a client computer system, and storage for executable code,said processor executing said executable code to provide an informationhandling capability to a client computer system by the steps ofidentifying factors relevant to provision of an information handlingfunction by said client computer, selecting one of at least a first anda second service to be uploaded to said client computer based upon saidfactors, said first and second services comprising different executablecode for providing said information handling function such that saidfirst and second services are capable of performing the same informationhandling function with differing levels of functionality, and deliveringsaid selected service to said client computer system, so that saidinformation handling capability may be realized by said client computerupon execution of code within said selected service at said clientcomputer system.
 12. A method of providing an information handlingcapability to a client computer system in a networked computer systemcomprising client and server computer systems, comprising the followingsteps executed at a client computer system: interacting with a servercomputer system such that state information relating to the interactionwith the server computer system is generated, after said interaction,receiving from a server computer system, executable code for providingsaid information handling capability, receiving from a server computersystem, said state information generated from said interaction of saidclient computer system and server computer system, utilizing said stateinformation while executing said executable code at said client toprovide said information handling capability.
 13. A client computersystem for providing an information handling capability in a networkedcomputer system comprising client and server computer systems,comprising: a processor, a communications interface for connecting to aserver computer system, and storage for executable code, said processorexecuting said executable code to provide said information handlingcapability, and to receive from a server computer system, stateinformation relating to a prior interaction of said client computersystem and server computer system, and to use said state informationwhile executing said executable code to provide said informationhandling capability, wherein said processor is further configured tointeract with a server computer system during said prior interactionsuch that said state information is generated from said priorinteraction.
 14. A method of providing an information handlingcapability to a client computer system in a networked computer systemcomprising client and server computer systems, comprising the followingsteps executed at a server computer system: selecting, in response to arequest to provide an information handling function by a client computersystem, a service to be executed by said server computer system, from atleast first and second services available to said server computer systemfor providing said information handling function such that said firstand second services are capable of performing the same informationhandling function with differing levels of functionality, and executingsaid executable code in said selected service to provide saidinformation handling function.
 15. The method of claim 14 furthercomprising identifying factors relevant to provision of the informationhandling function by said client computer, wherein selecting saidservice is based upon said factors.
 16. The method of claim 15 whereinsaid factors includes the operating system used by said server computersystem.
 17. The method of claim 15 wherein said factors includes theoperating system used by said client computer system.
 18. The method ofclaim 15 wherein said factors includes the bandwidth of a communicationsconnection between said client and server computer system.
 19. Themethod of claim 15 wherein said factors includes the date and/or time ofday.
 20. The method of claim 15 wherein said factors includes, the costof a communications connection between said client and server computersystem.
 21. The method of claim 15 wherein said factors includes thephysical location of said client and/or server computer system.
 22. Aserver providing an information handling capability to a client computersystem in a networked computer system comprising client and servercomputer systems, comprising: a processor, a communications interfacefor connecting to a client computer system, and storage for executablecode, said processor executing said executable code to select, inresponse to a request to provide an information handling function by aclient computer system, a service to be executed by said server computersystem, from at least first and second services available to said servercomputer system for providing said information handling function suchthat said first and second services are capable of performing the sameinformation handling function with differing levels of functionality,and then executing executable code in the selected service.